As is known, and referring now to FIG. 1, a rights management (RM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ the digital content with the aid of an appropriate rendering device such as a media player on a personal computer 14, a portable playback device or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and re-distributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. An RM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based RM system 10 allows an owner of digital content 12 to specify rules that must be satisfied before such digital content 12 is allowed to be rendered. Such rules can include the aforementioned requirements and/or others, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof, or such rules may already be attached to the content 12. Such license 16 may for example include the decryption key (KD) for decrypting the digital content 12, perhaps encrypted according to another key decryptable by the user's computing device or other playback device.
The content owner for a piece of digital content 12 would prefer not to distribute the content 12 to the user unless such owner can trust that the user will abide by the rules specified by such content owner in the license 16 or elsewhere. Preferably, then, the user's computing device 14 or other playback device is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to such rules.
The trusted component 18 typically has an evaluator 20 that reviews the rules, and determines based on the reviewed rules whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules, and the user should not be able to easily alter such trusted component 18 and/or the evaluator 20 for any purpose, nefarious or otherwise.
As should be understood, the rules for rendering the content 12 can specify whether the user has rights to so render based on any of several factors, including who the user is, where the user is located, what type of computing device 14 or other playback device the user is using, what rendering application is calling the RM system 10, the date, the time, etc. In addition, the rules may limit rendering to a pre-determined number of plays, or pre-determined play time, for example.
The rules may be specified according to any appropriate language and syntax. For example, the, language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the evaluator 20 determining that the user satisfies the rules, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from a pre-defined source and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered.
In an RM system 10, content 12 is packaged for use by a user by encrypting such content 12 and associating a set of rules with the content 12, whereby the content 12 can be rendered only in accordance with the rules. Because the content 12 can only be rendered in accordance with the rules, then, the content 12 may be freely distributed. Significantly, the content 12, the rules, and an encrypted version of the decryption key (KD) must be communicated to the computing device 14 or other playback device. Moreover, in preparing at least the encrypted version of the decryption key (KD), it is useful to tie the decryption key (KD) and by extension the license 16 containing such decryption key (KD) to the computing device 14 in such a manner that the encrypted decryption key (KD) cannot be accessed to decrypt and render the content 12 except by such computing device. Thus, the content 12, the rules, and the encrypted version of the decryption key (KD) cannot be redistributed in a manner so that the content 12 can be rendered widely and in contravention to the wishes of the content owner.
As may be appreciated, and as seen in FIG. 1, the encrypted decryption key (KD) and by extension the license 16 containing such decryption key (KD) are in fact tied to the computing device 14 by such decryption key (KD) being encrypted according to a public key (PU-BB) of the computing device 14 to result in (PU-BB(KD)). Presumptively, only the computing device 14 is in possession of the private key (PR-BB) corresponding to (PU-BB), and accordingly only such computing device 14 can apply (PR-BB) to (PU-BB(KD)) to reveal (KD).
In at least some instances, despite the content 12 being protected according to the RM system 10 and in the manner set forth above, the owner or distributor of such content 12 nevertheless has agreed to allow the content 12 to be copied or ‘burned’ in an unencrypted form to a portable medium 24 such as an optical disk or the like. Although allowing such burning of such unencrypted content 12 may seem to be in contravention of the purposes of the RM system 10, it is to be appreciated that there are nevertheless commercial and practical reasons for doing so, chief among them being consumer demand for such a feature. As should be appreciated, such a burn of the unencrypted form of the content 12 typically takes place along with a burn of a number of other pieces of unencrypted content 12, where each such piece of content 12 is a ‘track’ within. a ‘playlist’ representing all the pieces of content 12.
Although the owner or distributor of a piece of content 12 has agreed to allow the content 12 to be burned as a track in a playlist, the owner or distributor nevertheless may wish to impose restrictions on the ability to so burn. Most prominently, the owner or distributor may wish to limit the number of times a playlist with the content/track 12 can be burned. Accordingly, in a license 16 corresponding to the track 12, the content owner or distributor may impose a maximum playlist burn value specifying the maximum number of times a particular playlist with the track 12 can in fact be burned.
Note, though, that an issue arises when each track 12 is burned on a track-by-track basis. In particular, when in fact burning on a track-by-track basis, the trusted component 18 of FIG. 1 would be expected, for each RM-protected track 12, to determine based on a corresponding license 16 that the track 12 can in fact be burned as part of the playlist thereof. However, it may occur that after a number of tracks 12 of the playlist are successfully allowed to be burned by the trusted component 18, such trusted component 18 then refuses to allow a particular track 12 to be burned. If so, the burn of the playlist fails, and it may be the case that the portable medium 24 has been wasted, especially if not re-writable. In addition, and presuming the trusted component 18 has already changed one or more stored values corresponding to the licenses 16 of the tracks 12 that have already been burned, such changes to such values are likely not reversible and thus have also been wasted.
Accordingly, a need exists for a method and mechanism by which the tracks 12 of a playlist are burned on a collective basis. In particular, a need exists for a method and mechanism by which the trusted-component 18 determines that all of the RM-protected tracks 12 of the playlist can in fact be burned according to respective licenses 16 thereof prior to in fact burning any of such tracks 12. Also, a need exists for a method and mechanism by which the trusted component 18 does not in fact commit changes to values associated with the burn of the playlist until such trusted component 18 determines that all of the RM-protected tracks 12 of the playlist can in fact be burned.